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BACKGROUND OF THE INVENTION 
Field of the Invention 

The present invention relates to an electronic 
business transaction system for exchanging information of 
5 business transactions via a communication network and the 
like, and in particular, to an electronic business 
transaction system for electronically effecting business 
transactions between companies and firms via a 
communication network . 

10 

Description of the Related Art 

Recently, in the processing of business 
transactions between firms, there have been increasingly 
utilized electronic business transactions in which 

15 information of transactions are electronically 

communicated between firms via remote terminals of the 
firms through a network connecting the terminals to each 
other. For example, an example of such an electronic 
business transaction system has been described in pages 

20 83 to 92 of the "Electronic Settlement and Financial 

Reform" published from the Toyo Keizai Shimpo. According 
to the transaction system, data items of business 
transactions are exchanged via a network between firms in 
conformity with standardized rules to completely effect 

25 the business activity for the data items. Any firms to 
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achieve business transactions send data items such as a 
request for an estimate for articles and an indication of 
order of the articles to a mail box disposed on the 
network or data items such as an estimate in response to 
5 the request and a notification of delivery of articles- 
Through the operations above, the firms concerned can 
communicate data items therebetween to accomplish desired 
business • 

However, it is impossible in accordance with 
10 the prior art to carry out an operation to authenticate 
members who conduct transactions and/or an operation to 
prove the contents and time of transaction data and names 
of members related to the transaction. Additionally, the 
business transaction between firms is substantially 
15 achieved only between two firms which have been 

beforehand recognized as business partners, i.e., only 
one-to-one business transactions have been taken into 
consideration. That is, the conventional technology is 
attended with a drawback that an open transaction or open 
20 business such as an open purchase in which a large number 
of firms participate cannot be achieved. 

Furthermore, the prior art requires each member 
to individually conduct management jobs including 
management of issued orders and accepted orders. 
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SUMMARY OF THE INVENTION 

It is therefore an object of the present 
invention, which has been devised to solve the problem 
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above, to provide an efficient business transaction 

system in which the desired operations are 

comprehensively integrated in one system to treat 

information necessary for business transactions in a 

5 concentrated fashion - 

To achieve the object, there is provided an 

electronic business transaction system in which business 

transactions are electronically effected between firms at 

their sites of remote terminals connected via a network 

10 to each other, the system including a center oido to 

A- 

intervene in business transactions achieved through the 
network. The center site includes an open business 
information database to store therein open business 
information which is received from sites connected to the 

15 network which offers articles for buyers in an open 

business and a notarization database to keep therein the 
contents of contracts associated with business 
transactions effected between the respective sites via 
the network. The open business information accumulated 

20 in the database can be accessed by any site linked with 
the network such that a request from a firm for business 
for an information item of open business is accepted and 
is then notified to the site of the pertinent information 
supplier. Additionally, the center site intervenes in 

25 the transaction resultantly accomplished between the 

information supplier site and the transaction requesting 
site to carry out a notarial act for the content of 
business contract between the partners and then 
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acciimulates the notarized contents of contract in the 
notarization database. 

Moreover, the center site gathers information 
whether or not the delivery and settlement have been 
5 conducted in conformity with the contract from the 

related sites to store the information together with the 
contents of contract and then transmits a message to 
press for the deliver or settlement to the related sites. 

Another object of the present invention is to 

10 manage, in an environment in which databases including 
cases of respective, information source firms are 
distributively arranged, statuses of transmission of 
cases related to respective information receiver firms in 
a centralized and concentrated manner to avoid occurrence 

15 of business trouble. 

In accordance with the present invention, there 
is provided a method of managing statuses of transmission 
of cases for transactions between firms. For each 
information transmission source, the status of 

20 transmission of cases related to each information 

receiver is stored in first storage. In response to 
registration of a new case from the information 
transmission source, the status of transmission of cases 
of the associated information receiver is updated- For 

25 each information receiver, the status of transmission of 
cases of each information source is stored in second 
storage. In response to an update operation of the cases 
from the information receiver, the status of transmission 
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of cases of the associated information source is updated. 
In response to an enquiry from the information receiver, 
the second storage is referred to such that the statuses 
of transmission of cases from the respective information 
5 sources for the pertinent information receiver are 

transmitted to an information receiver to receive the 
answer to the inquiry. 

If the information receiver issues a case 
acquisition request for the cases of transmission with 
10 indication of a particular information transmission 

source, cases specified as above are obtained from an 
associated business database to be sent to the 
information receiver having issued the request. 

BRIEF DESCRIPTION OF THE DRAWINGS 
15 The objects and features of the present 

invention will become more apparent from the 
consideration of the following detailed description taken 
in conjunction with the accompanying drawings in which: 
Fig. 1 is a diagram showing the configuration 
20 of an embodiment of a business transaction system in 
accordance with the present invention; 

Fig. 2 is a flowchart showing a flow of 
operations of accepting or registering a new member site; 

Fig. 3 is a flowchart showing a job flow of a 
25 business transaction between two member sites; 

Fig. 4 is flowchart showing an operation flow 
of an open purchase; 
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Fig. 5 is flowchart showing an operation flow 
of an open sale; 

Fig. 6 is a diagram showing an example of 
layout of a member information database; 
5 Fig. 7 is a diagram showing a layout example of 

the authentication database; 

Fig. 8 is a diagram showing an example of 
layout of the notarization database; 

Fig. 9 is a diagram showing a layout example of 
10 a contacted amount information database; 

Fig. 10 is a diagram showing an example of 
layout of an open business information database; 

Fig. 11 is flowchart showing a flow of balance 
netting operation; 
15 Fig. 12 is a diagram for explaining a method of 

netting balances within a group and between groups; 

Fig. 13 is a block diagram showing the - 
configuration of a business transaction system between 
firms ; 

20 Fig. 14 is a diagram showing an example of data 

of cases in a case database 1311 of Fig. 13; 

Figs. 15A and 15B are diagrams showing an 
example of data in a case count information database 
1312; 

25 Figs. 16A and 16B are diagrams showing an 

example of data in a service status database 1312; 

Figs. 17A and 17B are flowcharts showing a flow 
of processing of a business server status management 



- 7 - 

program 1322; and 

Figs. 18A and 18B are flowcharts showing a 
processing flow of a service and server status management 
program 1322. 

5 DESCRIPTION OF THE PREFERRED EMBODIMENTS 
Embodiment 1 

Description will now be given in detail of an 
embodiment in accordance with the present invention. In 
this connection, the present invention is not restricted 
3 10 by the embodiment. 

3 Fig. 1 shows the structure of an embodiment of 

S an electronic business transaction system according to 

f\ the present invention. The system includes member sites 

20 to 50 which participate as members of the embodiment 
% 15 of the transaction system in electronic business 
't transactions and a center site 10 to provide services to 

the member sites. The center site 10 is mutually 
connected via a network 70 to the member sites 20 to 50. 
Moreover, the center site 10 is coupled with an external 
20 network 90. The term "external network" represents a 
network other than the constituent elements of the 
electronic business transaction system, i.e., a network 
such as the Internet constituting another electronic 
business transaction system. Each member site can be 
25 connected via the center site 10 to the external network. 

For safety and security, the network 70 is 
desirably a closed network using a leased line; however. 
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there may be adopted a public telephone line and the 
Internet. 

Each of the center and member sites includes 
such an information processing apparatus as a personal 
5 computer, a workstation, a main frame computer each 
including a communication line interface. 

The center site 10 includes a member 
information database 110 to control information related 
to the respective member sites of the transaction system, 

10 an authentication database 120 to authenticate verify 

each member site, a notarization database 130 to notarize 
transaction data in the business transaction achieved 
between member sites, a contract amount information 
database 140 to manage information of the contracted 

15 amount of the business transaction between member sites, 
and an open business information database 150 to supply 
various sales and purchase information to the respective 
member sites . These databases are stored in an external 
storage of the information processing apparatus. 

20 The center site 10 includes a controller 100 

which supervises programs included therein to control the 
databases so as to implement various functions provided 
by the center site 10. The controller 100 includes a 
processor and a memory of the information processing 

25 apparatus and executes various software programs by the 
processor to achieve the functions. 

The member sites 20 to 40 mutually carry out 
business transactions therebetween and are operated by a 
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manufacturer, a distributor, a shipping agent, a buyer, 
and the like. The member site 50 includes a settling 
function to settle business transactions accomplished by 
the other member sites 20 to 40. The site 50 is 
5 operated, for example, by a bank. Although four member 
sites are arranged for convenience of explanation in this 
embodiment, there may be disposed more member sites to be 
connected to the system. 

Communications of requests, acceptance of 

10 requests, and associated data items between the center 

site 10 and the member sites 20 to 50 are carried out in 
conformity with a protocol, for example, TCP/IP used by 
the network 70. The center and member sites have a 
function to produce a frame including request or 

15 reception data after enciphering process in accordance 
with a specified protocol and to send the frame to the 
network. These sites further include a function to 
receive a frame via the network and extract necessary 
information therefrom with deciphering process . 

20 Fig. 2 is a flowchart of a processing flow in 

the center site 10 at reception of a request for 
subscription from a new site. Receipt of subscription is 
conducted by the center site 10 (step 200). The 
operation may be carried out, for exemfiple, by receiving 

25 an electronic mail via the external network 90. The 

center site 10 determines acceptance or rejection of the 
request for subscription in accordance with the size of 
enterprise, the amount of capital, and the business 
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transaction history of the new site. The judgement may 
be accomplished by a human or may be automatically 
achieved by the center site 10 on the basis of 
predetermined judging criteria using a credit information 
5 database installed in the center site or another 

institution (step 202). After accepting subscription of 
the new site, the center site 10 issues an identification 
number which is unique in the system and a cryptographic 
key for encryption (steps 204 and 206) and then finally 

10 registers information of the request issuing site to the 
member information data base 110 and information of 
authentication thereof to the authentication database 
120. After the credit giving operation is completed, the 
requesting site, i.e., the member site accesses the 

15 center site via the network 70 by use of the assigned 
identification number. The member and center sites 
communicate with each other in conformity with a. 
cryptographic system using the cryptographic key. The 
encryption may be achieved in accordance with the 

20 conventional method such as private-key cryptosystem 
(DES) or public-key cryptosystem ( RAS) . The 
anthentication may be accomplished by exchaging 
certificate each other in accordance with ITU-T 
Recommendation X. 509. 

25 Fig. 6 shows configurations respectively of the 

member information and authentication databases 110 and 
120. 

The member information database 110 may 
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includes, in addition to the correspondence between the 
identification numbers and member sites, information 
items such as a firm to which the member site belongs, a 
firm group of the site, the amount of capital, and a type 
5 of business of the firm. The information items may be 
transmitted from the member site to the center site at 
the subscription. Alternatively, when checking the grade 
of credit of the member site (step 202), the center site 
may acquire the information from another database. 

10 In the authentication database 120, there may 

be stored an authentication level in addition to the 
identification number, the password, and the 
cryptographic key for the following reasons. Namely, 
with the provision, it is possible to set limits to the 

15 access right, a range of transaction partners, the 

contents of transaction, and/or the amount of transaction 
for databases disposed in the center site. The 
authentication level includes levels A to E predetermined 
in the system. When checking the credit of the member 

20 site, the center side determines one of the levels for 
the site to register the determined levels to the 
authentication database 120. To prevent the data from 
being surreptitiously viewed for wrong purposes or from 
being falsified by unauthorized persons, the data is 

25 encrypted before being stored in the database 120. 

Fig. 3 is a flowchart showing an example of the 
job flow of achieving business transactions between two 
member sites. In the example, it is assumed that a 
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member site 20 purchases articles or items from a member 
site 30. 

First, the site 20 desiring the purchase of 
articles issues a login request to the center site 10. 
5 The site 10 receives the request from the site 20 (step 
300). Thereafter, the center site 10 verifies an 
identification number and a password of the request with 
those registered to the authentication database 120 to 
authenticate the member site 20 (step 302). VHien the 

10 authentication of the member site 20 is finished, the 

center site 10 receives a purchase form from the site 20 
and the sends the form to an appropriate article 
supplying site, i.e., the member site 30 (step 304). The 
purchase form includes an article number, a quantity of 

15 articles, a price, a delivery date, a member name who 
issues order, a member name who accepts order, and an 
order number. 

Subsequently, the center site 10 receives an 
order acceptance form from the supplying site 30 and 

20 transfers the form to the ordering site 20 (step 306). 
The order acceptance form includes an article number, a 
quantity of articles, a price, a delivery date, a date of 
payment, a member name who issues order, a member name 
who accepts order, and an order number. On this 

25 occasion, when the conditions above are satisfactory for 
the associated partners, the center site 10 receives a 
contract document or form from each thereof (step 308). 
The contents of "the contact are substantially the same as 
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those of the order acceptance form. When the contact 
documents received from both sites match each other, the 
center site 10 conducts, to guarantee the contents of 
contract, an notarizating operation, for example, by 
5 electronically signing on the received contact documents 
and thereafter stores the documents in thes notarization 
database 130 (step 310), 

The notarization may be accomplished by the 
center site 10 or by an external notarization institution 
10 connected to the site 10. Fig. 8 shows structure of the 

St; 

3 notarization database 130. Furthermore, the site 10 

S records the contracted amount of the member sites 20 and 

^ 30 in the contracted amount information database 140 

;= (step 312). Fig. 9 shows constitution of the database 

15 140. The center site 10 then calculates an amount of 
^ charge for the utilization of the electronic business 

y transaction system for each of the sites 20 and 30 to 

3 record the amount of charge of each member site in the 

member information database 110 (step 314). Finally, the 
20 center site 10 notifies the completion of contract to the 
member sites 20 and 30 to thereby terminates the sequence 
of operations for the business transaction (step 316). 

Fig. 4 shows in a flowchart a flow of 
processing executed by the center site 10 for an open 
25 purchase effected among member sites. When a member site 
desiring the purchase of items (a member site 40 in this 
explanation) issues a login request, the center site 10 
receives the login request (step 400). The site 10 
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authenticates the site 40 by referring to the 
authentication database 120 (step 402). Having 
authenticated the site 40, the site 10 receives a request 
for open purchase from the site 40 and registers the 
5 request as open business information to the open business 
information database 150 (step 404). Fig. 10 shows 
structure of the database 150. The registered 
information is opened to member sites satisfying the 
condition of the specified transaction range. The center 
10 site 10 may send the information to the member sites by 
3 mail or may send to member sites in response to a request 

j therefrom (step 406). 

When it is recognized that either one of the 
iil sites desires to accept the order, order receiving 

^ 15 information is transmitted from the site to the center 
y site 10 (step 408). On receiving the information, the 

y site 10 carries out the authentication for the member 

3 site (step 410). After the authentication of the site, 

information related thereto is reported to the purchasing 
20 member site, i.e., the site 40 (step 412), In the site 
40, the operator checks the order receiving 
specification, the order receiving conditions, and the 
like in accordance with the information of the pertinent 
site. Resultantly, the site 40 selects an order 
25 receiving partner from the member sites desiring the 

reception of order and then notifies the member site to 
the center site 10. Thereafter, the site 10 receives 
contract documents respectively from the site 40 and the 
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order receiver site determined by the site 40 (step 416) 
to accomplish notarization for the transaction (step 
418), Like the transaction between sites shown in Fig. 
3, the registration of the amount of contract, the 
5 charging operation, and the notification of completed 
contract are performed (step 420 to 424). The center 
site 10 then set a processing completion flag to the 
pertinent record of the open business information 
database 150 (step 426). As a result, the record is not 
10 to be subjected to the open operation thereafter. When a 
J predetermined period of time lapses, the record may be 

3 deleted or may be moved to another file for the storage 

2 thereof . 

The operation of the open purchase between the 
15 member sites can also be implemented for an open purchase 

ST 

2 between various sites including external sites. In such 

y a situation, the operation in step 406 to notify the open 

3 purchase information is also carried out for the external 
network 90 in addition to the network 70. Additionally, 

20 in step 408, the desire for reception of order is 

received via the external network 90 from external sites. 
In step 410, the authentication is processed for the 
external site in the same way as for the member sites . 
However, in some cases, an operation to give credit to 

25 the external site may be required in the processing. 

Fig. 5 is a flowchart showing a processing flow 
of an open sales operation. The processing is executed 
in a procedure substantially similar to that of the open 



purchase, A member site desiring a sales operation 
issues a login request via the network 70 and then the 
center site 10 receives the request (step 500). After 
the login is finished, the site 10 authenticates the 
member site (step 502), Receiving a sales form from the 
site, the center site 10 registers the contents of sales 
form as open business information to the open business 
information database 150 (step 504). The received open 
sales information is opened, like the open purchase 
information, via the network 70 to the respective member 
sites (step 506). When any member desiring the purchase 
of articles related to the information sends a request 
for purchase, the center site 10 receives the request 
(step 508). Receiving the request from each site 
desiring the purchase, the center site 10 authenticates 
the member site according to the authentication database 
120 (step 510). After the authentication, the purchase 
request from the site is sent to the sales member site 
(step 510). The sales member site selects a purchasing 
member site from the candidate purchasers and notifies 
the purchaser site to the center site 10 (step 512). 
Processing thereafter (steps 514 to 526) is almost the 
same as that of the open purchase. 

In this regard, although description has been 
given of the processing procedure of an open sales 
operation between member sites, an sales operation 
including external sites can also be carried but in the 
same manner as for the open purchase including external 
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sites . 

In the transactions shown in Figs, 3 to 5, when 
the pertinent member site is authenticated, the center 
site 10 unconditionally receives the purchase and sales 
5 forms (steps 304, 404, and 504). At reception of the 
form, the center site 10 may check again on the basis of 
the authentication level in the authentication database 
120 whether or not a transaction in the form is allowed 
for the member site, thereby accepting the purchase or 
10 sales form, 

% In the open purchase and sale shown in Figs , 4 

J and 5, the contents of purchase and sale are opened to 

the member sites. By issuing an enquiry request to the 
L! center site 10, any member site can refer to the contents 

15 of the database 150. In this situation, the center site 
U 10 examines the transaction range (Fig. 11) in the 

y database 150 and the authentication level (Fig. 7) to 

J resultantly supply the member only with information 

within a transaction range allowed for the member. In 
20 the enquiry request, the member may optinally specify a 
kind of article, range of amount of money, and the like 
such that the center site 10 appropriately classifies, 
selects, and sorts associated data items of the database 
150 in accordance with the optional specifications to 
25 accordingly send resultant information to the members. 

The controller 100 of the center site 10 may 
includes function described as follows. 

The site 10 may carry out the netting (offset 



- 18 - 

amount) operation of balance between the member sites. 
In the business transaction system of Fig, 1, information 
of the contracted amount information database 140 is 
transmitted to a member site having a function of 
5 settlement to achieve the settlement processing. 
However, the settlement operation is charged in 
accordance with the number of cases and the amount of 
money in many cases. Consequently, the settlement 
processing is carried out in some cases after the netting 
10 operation is finished. 
% Fig. 11 is a flowchart showing a flow of 

netting operation conducted by the center site 10 to net 
''^ the balance. Since member sites form groups of related 

firms in most cases, the netting operation is conducted 
15 in such a group or between a firm in the group and a firm 
y not belonging to the group. In the netting operation, 

U the contracted amount information database 140 is 

=1 accessed to extract therefrom records for the netting of 

balances and the groups of the respective members are 
20 determined by the member information database 110 to 

thereby generate a table on the main memory as shown in 
Fig. 12. 

In the processing, the balance of each member 
site is calculated in accordance with the contracted 
25 amount information recorded in the database 140 (step 
1100). Next, according to the results of calculation, 
the balance is obtained between the member sites in a 
group (step 1102). Additionally, the balance is 
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calculated between the groups of member sites (step 
1104). Information of balances resultant from these 
operations is reported from the center site 10 to a 
member site 50 possessing a function of settlement such 
5 that the settlement is accomplished in the member site 50 
(step 1106). Moreover, the center site 10 may notify the 
balance information sent to the site 50 to a member site 
of the group controlling member and related member sites 
(steps 1108 and 1110). The groups may be configured 
10 , 4Mrevachically and such information may be managed on the 

A 

member information database 110 in the center site 10. 

Fig. 12 is a diagram for explaining netting 
procedures in a group and between groups . In the 
diagram, Al to A3, Bl , B2 , CI and C2 represent member 

15 names. The vertical line stands for the supplier 

(selling) side and the horizontal line designates the 
procurer (purchasing) side. Since one member purchases 
and sells articles, the same member names appears along 
the vertical and horizontal lines . Assume that Al to A3 

20 configure group A, Bl and B2 form group B, and CI and C2 
constitute group C. T indicates the overall group, for 
example, AT denotes the entire body of group A; 
moreover, TT represents all groups ranging from group A 
to group C. In Fig. 12, the intersection between the 

25 vertical and horizontal zones indicates the amount to be 
paid from the member related to the vertical column to 
that associated with the horizontal row. For example, 
viewed from member Al as a supplier, an amount of A1A2 is 
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to be received from member A2 and an amount of AlAT is to 
be received in the group. In the groups, an amount of 
AITT is to be received. Similarly, viewed from member Al 
as a supplier, an amount of A2A1 is to be paid to member 
5 A2 , an amount of ATAl is to be paid in group a, and an 
amount of TTAl is to be paid in the groups . When the 
balance netting is carried out in group A, member Al need 
not individually pay the amounts to members A2 and A3, 
namely, it is only necessary to pay an amount of ATAl to 

10 the supervisor of group A. When setting with group B, 
member Al need only pay an amount of BTAl to the 
supervisor of group B. When the netting operation is to 
be achieved between groups after the balance netting is 
completely achieved in each group, it is necessary, for 

15 example, group A to pay an amount of TTAT to the overall 
netting system. As above, all combinations of netting 
operations can.be coped with. 

The center site 10 may include a check function 
to determine whether or not the delivery and/or the 

20 payment have/has been conducted in conformity with the 
contract. In the notarization database 130, there is 
disposed items for the delivery date and the date for 
payment. It may also possible to provide an item of a 
payment completion flag in the contracted amount 

25 information database 140. The order issuing site and/or 
the order receiver site report /reports the event of 
delivery to the center site 10 together with the contract 
number. The site 10 sets the delivery date to the 
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pertinent record related to the contract number in the 
notarization database 130. The site having the settling 
function notifies the event of settlement to the center 
site 10 together with the contract number. In response 
5 thereto, the site 10 sets the payment date to the 

pertinent record associated with the contract number in 
the database 130 and the payment completion flag to the 
database 140. Periodically examining the databases 130 
and 140, the center site 10 extracts therefrom contract 

10 numbers for which the delivery and/or the payment are/is 
overdue to send a warning message to sites associated 
with the contract numbers. 

Any member site can issue an enquiry request to 
the site 10 for the status of contracts related thereto. 

15 The enquiry request may includes a contract number, an 
item number, and a transaction partner. The site 10 
acquires necessary records from the databases 130 and/or 
140 to transmit the records to the associated member 
sites. 

20 The records in the databases 130 and 140 may be 

deleted or moved to another journal file when a 
predetermined period lapses after the delivery and the 
payment are finished. 

M 

It may also possible to store the past 
A 

25 contracts and the implementation status of contracts in 
the journal file for ranking the firms which the member 
sites belong to. 

The center site 10 extracts for each site the 
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amount of transactions, a rate of retarded delivery, and 
a rate of retarded payment from the history file to rank 
the firms in accordance with a predetermined evaluating 
function. 

The ranking information may be utilized and/or 
opened as data for the decision of business transaction, 
judgement for credit of the partner, and the like. 

In addition to the services for business 
transactions between the member sites, the center site 10 
provides the following services. The site 10 delivers 
various software articles to member sites so that the 
member sites access the system for desired services, 
conducts maintenance such as the update and management of 
software versions, supplies test environments of software 
and hardware, and lends system resources to member sites. 
Moreover, to help member sites access the external 
network 90, the site 10 provides a device to convert 
communication protocols and identifiers. Additionally, 
it is also possible that the site 10 cooperates with 
systems installed at member sites to supply information 
of the delivery date and the arrival date of ordered 
articles or supplies information managed by the site 10 
to particular members. Due to this function, there is 
provided a service that the particular members can 
conduct jobs for other members. 

Embodiment 2 

This embodiment includes a system for and a 



- 23 - 

method of enabling statuses of any data (cases) to be 
referred to in a system in which a server to manage data 
of orders is provided for each firm or enterprise. 

Fig. 13 shows the system configuration of a 
5 part of a business transaction system for processing 

transactions between firms in accordance with the present 
invention. The configuration includes business servers 
1302 which are computers to conduct business services 
between companies and which include a server 1303-1 of 
10 office S of firm A, a server 1302-2 of office U of firm 
B, and the like respectively for information transmitting 
l'^ firms and/or for branches or offices of a firm. The 

system further includes a service status server 1304 
I'L: which is a computer to manage service statuses of all 

;^ 15 business servers 1302, clients 1305 which are computers 

ry to access the business servers 1302 and the service 

ry status server 1304 for desired services and which include 

•i i? 

Q a client 1305-1 of office S of firm A, a client 1305-2 of 

office U of firm B, and the like respectively for firms 

20 and/or for offices of a firm; and a network 1310 to 

establish connections between the business servers 1302, 
the service status server 1304, and the clients 1305. 

The server 1302 includes a case database (DB) 
1311, a case quantity information database 1312, a 

25 business program 1321, and a status management program 

1322. The case database 1311 is a database disposed in a 
storage of the server 1302 to store therein case data for 
which an information receiver is specified and open cases 
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for which specification of information receivers is not 
specified. The case count information database 1312 is a 
database arranged in a storage of the server 1302 to 
store therein for each receiver the nximber of cases for 
which the receivers are specified. The business program 
1321 includes programs to execute job services in 
response to requests from the clients 1305, i.e., the 
business program registers case data to the case database 
1311, refers to and updates case data therein, and 
deletes case data therefrom. The status management 
program 1322 includes programs which updates, at 
reception of registration and deletion of case data to 
and from the database 1312 from the program 1321, the 
service status, i.e., the number of cases in the database 
1312 and notifies the status to the service status server 
1304. The status management program 1322 transmits, on 
receiving an enquiry from the client 1305, the contents 
of the database 1312 to the client; updates the number of 
cases of the database 1312 when acquisition of a case is 
notified from the client, and reports the status to the 
service status server 1304, The seirvers 1302-2 and 1302- 
3 as well as the server 1302-1 are configured in a 
similar fashion. In the description below, the business 
server 1302 represents either one of these servers for 
the associated services. 

The service status server 1304 includes a 
service status database 1313 and a status management 
program 1323. The database 1313 is disposed in a storage 
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of the server 1304 to store therein for each receiver a 
table of cases for which receivers are specified such 
that the number of cases is stored for each receiver in 
the receiver table. On receiving a status report from 
5 the program 1322 of the business server 1302, the program 
1323 updates the receiver table associated therewith. In 
response to an enquiry from the client 1305, the program 
1323 edits the contents of the receiver table to transmit 
the edited results to the client 1305. 
10 The client 1305 accomplishes processing of 

businesses in association with the business program 1321 
1^ of the serve 1302. Namely, the client 1305 registers 

"L: case data to the case database 1311, refers to and 

updates data therein, and deletes case data therefrom. 
15 In relation to the status management program 1322, the 
ry client 1305 notifies the number of cases of which the 

ry contents are referred to and that of the cases obtained. 

i;3 In connection with the status management program 1323 of 

the service status server 1304, the client 1305 refers to 
20 the pertinent receiver table in the service status 

database 1313. Assume in the description below that the 
client 1305 designates either one of the clients 1305-1, 
1305-2, etc. in association with the related services . 

The status management programs 1322 and 1323 
25 are respectively stored on recording media and are sent 
respectively via drivers connected respectively to the 
business server 1302 and the service status server 1304 
to be stored in the main storage of the computer; 
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alternatively, these programs are respectively delivered 
via program transfer operations to the business server 
1302 or the service status server 1304 to be then stored 
in the main storage of the computer. These programs are 
5 ready for execution in this state. 

It is to be appreciated that the network 1310 
collectively denotes an entire network including 
constituent elements such as a leased line, an integrated 
services digital network (ISDN), a local area network 
10 (LAN), a wide area network (WAN), and the Internet. 

Firms or offices in a firm which take part in 
'J the business transaction system shown in Fig. 13 are 

■ ;j registered as members of the system to a member 

management server, not shown. When the client 1305 
15 accesses the business server 1302 or the service status 
fy server 1304, there is achieved the authentication of 

-if membership for the member. Description will be now given 

i is? 

of an outline of the processing procedure in the overall 
system from when an information transmitting member 

20 register data of a case to the case database 1311 to when 
an information receiving member attains the case data. 
On receiving a request from the client 1305 related to 
the information transmitting member to register a case, 
the business progrcim 1321 of the server 1302 registers 

25 data of the case including an identifier of the 

information receiver to the database 1311 and reports the 
registration thereof to the status management program 
1322, The program 1322 updates the number of cases of 
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the pertinent receiver in the case count information 
database 1312 and notifies the updated service status via 
the network 1310 to the status server 1304. Based on the 
status report, the program 1323 updates the number of 
5 cases for the pertinent transmitting source in the 

receiver table in the database 1313. Resultantly, the 
number of cases of each transmitting source is 
accumulated in each receiver table in the database 1313. 
On receiving an enquiry of the service status from the 
10 client 1305 as the information receiver, the status 

sc. 

5 management program 1323 refers to the databases to edit 

^ the associated receiver table and then sends the table to 

ii 

« the client 1305 having issued the enquiry. The client 

L; 1305 displays the receiver table on a display. In 

15 response to a request of indication from a member for the 
^ number of acquired cases and a transmitting source, the 

y client 1305 sends a request of the number of cases to a 

3 business server 1302 of the transmitter. The business 

program 1321 of the server 1302 refers to the case 
20 database 1311 to attain requested data of cases for which 
the pertinent receiving partner is specified and then 
sends the data to the client 1305, When the notification 
of reception is sent from the client 1305 to the business 
server 1302, the program 1322 receives the notification, 
2 5 subtracts the number of obtained cases from the number of 
cases of the related receiver in the database 1312, and 
then notifies the updated service status to the server 
1304. In response to the status notification, the 
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program 1323 updates the number of cases for the 
pertinent transmitting source in the associated receiver 
table in the database 1313, 

Fig. 14 shows an example of data for one case 
5 in the case database 1311 including data items such as a 
case number, an order issuing partner, an order receiver, 
a degree of urgency, and a read flag. The case number is 
an identifier for data of one case, the order issuing 
partner includes an identifier for a partner having 

10 issued an order, the order receiver is an identifier for 
a partner having received an order, a degree of urgency 
includes a flag for discrimination between an urgent case 
and an ordinary case, and a read flag is a flag to 
indicate whether or not the pertinent case has been 

15 referred (the transaction has been effected) by the order 
receiver. In addition, for each item ordered, there are 
provided such data items as an item name, a quantity of 
items ordered, an amount for items ordered, and a 
delivery data. The item name is an identifier of the 

20 items, the quantity of items ordered stands for the 

number of ordered items, the amount for items ordered 
indicates an amount assumed by the ordering partner and 
is referred to by the order receiver in the response to 
the order, and the delivery data designates a deliver 

2 5 date desired by the order issuing partner and is used by 
the order receiver in the response to the order. In this 
connection, the order receiver, the degree of urgency, 
and the read flag are missing in an open case. There are 
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additionally disposed classifying items such as a type of 
business and a kind of products to identify the pertinent 
item. 

Figs. 15A and 15B show examples of data in the 
5 case count information database 1312. Fig. 15A shows a 
data example of a case for which a receiver of case data 
is specified. Each record of the database 1312 includes 
data items such as a receiver, a type of information, and 
a degree of urgency, and a number of cases. The receiver 
10 is an identifier of a partner to receive case data and is 
5 an identifier of the order receiving partner in a case of 

Z an ordering event. The type of information is a flag for 

v! discrimination of the case between a business case and a 

message (information supplying) case. The degree of 
15 urgency is a flag for discrimination of the case between 
y an urgent case and an ordinary case. The number of cases 

y includes the quantity of cases accumulated for each 

3 receiving partner, each type of information, and each 

degree of urgency. Fig. 15B shows a data example of an 
20 open case for which a receiver of case data is not 

specified. Each record includes data items such as an 
order issuing partner which is expressed by an identifier 
of the partner having issued case data and a type of 
information which is a flag for discrimination of the 
25 case between a business case and a message case. The 
record further includes a type of business, a kind of 
items, and a type of products which hierarchically . 
indicates business types and products. Moreover, the 
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record includes a number of cases which designates the 
quantity of cases accumulated for each order issuing 
partner, each type of information, and each type of 
business, each kind of items i and each type of products. 
5 Figs. 16A and 16B show data excimples of the 

service status database 1313. Fig. 16A shows an example 
of data for which a receiver of case data is specified. 
The database 1313 includes a summary table storing the 
total number of cases of each receiving partner and 
10 detailed receiver tables disposed for respective 
i receiving partners. Stored in the summary table are the 

I total number of business cases and the total number of 

Li message cases for each identifier of receiving partners, 

L! Each record of the receiver table includes such data 

15 items as an identifier of a transmission source, a type 
y of information, a degree of urgency, a number of cases, 

y and update day and time. The update day and time 

3 includes day and time when the pertinent record is 

updated. The total number of each type of information in 
20 the detailed table of each receiver is equal to that of 
the type of information of the receiver in the summary 
table. Fig. 16B shows an example of data for which a 
receiver of case data is not specified. The database 
1313 includes a summary table to store the total number 
25 of cases and detailed receiver tables disposed for 

respective transmitting partners. Stored in the summary 
table are the total number of business cases and the 
total number of message cases. Each record of the 
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detailed table includes data items such as an identifier 
of a transmission source, a type of information, a type 
of business, a kind of items, a type of products, a 
number of cases, and update day and time* The items 
5 ranging from the transmitting source to the type of 

products are the same as those of Fig. 15B. The update 
day and time includes day and time when the pertinent 
record is updated. 

On receiving a request for registration of case 

10 data from the client 1305 via the network 1310, the 

business program 1321 generates case data in accordance 
with data supplied from the client 1305, adds a case 
number thereto, and registers the resultant data to the 
case database 1311. The program 1321 sets the read flag 

15 of the case data to ''not read". Thereafter, the program 
1321 reports the new registration of case data to the 
status management program 1322. 

Figs. 17A and 17B are flowcharts showing a flow 
of processing of the program 1322. Fig. 17A shows an 

20 operation to update the case count information database 
1312 in relation to the registration of case data. When 
the registration report including the case number of the 
new case thus registered is received from the business 
program 1321 (step 1731), the status management program 

25 1322 refers to the case database 1311 to acquire 

therefrom specified case data (step 1732), determines the 
type of information, and updates the database 1312 by 
adding one to the number cases in a record associated 
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with the pertinent receiving partner, information type, 
and degree of urgency (step 1733). When a case is 
invalidated by, for example, a deleting operation, the 
program 1322 subtract one from the number of cases in a 
5 pertinent record of the database 1312. The program 1322 
then sends the updated status via the network 1310 to the 
status management program 1323 of the service status 
server 1304 (step 1734). The data sent from the program 
1322 to the program 1323 includes a transmission source, 

10 a receiving partner, a type of information, a degree of 
urgency, and a number of cases. The transmission source 
is an identifier of an operator (e.g., an order issuing 
person) who have registered the case to the database 
1311, Also in a case in which an open case is to be 

15 registered, the program 1322 receives a notification of 
registration from the business program 1321, refers to 
the case database 1311 to add one to the number of cases 
in a record related to the associated transmission 
source, information type, type of business, kind of 

20 items, and type of products, and then transmits the 

updated status to the control program 1323. When the 
case is deleted or withdrawn, the progreim 1322 subtracts 
one from the number of cases in the pertinent record of 
the database 1312 and sends the updated status to the 

25 control program 1323. 

Fig. 17B is a flowchart showing a flow of 
processing of the status management program 1322 in 
association with an enquiry or a notification of case 
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acquisition for the database 1312 issued from the client 
1305. When an enquiry or a notification of case 
acquisition for the database 1312 is received from the 
client 1305, there is conducted authentication of the 
5 user by a member management server, not shown. For an 
authenticated user, control is passed to the status 
management program 1322 of a business server 1302 
specified as the destination. The program 1322 receives 
an enquiry or a notification of case acquisition from the 
10 client 1305 (step 1741). The enquiry or the notification 

as. 

^ of case acquisition includes an identifier of the member 

J to which the client 1305 belongs. For a notification of 

il acquisition, there are notified the number of cases for 

ft the type or information and for the degree of urgency of 

15 the case obtained by the receiving partner. When the 

Si 
-I 

]l member is an information transmission source to control 

|1 the pertinent business server 1302 and the received data 

i_ indicates an enquiry (yes in step 1742), the program 1322 

refers to the database 1312 to edit the entire 
20 information of the database 1312 to send the resultant 
data to the client 1305 which issued the enquiry (step 
1743). When the member is other than the information 
transmission source to control the pertinent business 
server 1302 and the received data indicates a 
25 notification of acquisition (no in step 1742), the 

program 1322 refers to the database 1312 to subtract one 
from each of the numbers of cases respectively associated 
with the type of information and the degree of urgency to 
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thereby update the case count information database 1312 
(step 1744). Subsequently, the program 1322 transmits 
the updated status via the network 1310 to the status 
management program 1323 (step 1745). The data sent from 
5 the program 1322 to the program 1323 is substantially the 
same as that of step 1734. For an open case, when the 
received item indicates an enquiry for the database 1312, 
the program 1322 sends the entire information of the 
database 1312 to the client 1305 as above. However, for 

10 a notification of acquisition, the program 1322 does not 
update the database 1312. 

Figs. 18A and 18B are flowcharts showing 
operations conducted by the status management program 
1323. Fig. 18A shows processing to update the service 

15 status database 1313 in response to a report from the 

status management program 1322. When an updated status 
is received from the program 1322 (step 1851), the 
program 1323 updates the status database 1313 in 
accordance with the received data (step 1852). Namely, 

20 in a detailed table in the database 1313 related to the 
receiving partner, the number of cases is updated with 
the received value in records respectively associated 
with the pertinent transmission source, information type, 
and degree of urgency and then the update day and time 

2 5 are updated. Moreover, in the summary table, the total 
numbers respectively of job and message cases of the 
pertinent receiving partner are increased or decreased in 
association with the increase or decrease in the detailed 
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table. When receiving a status report of an open case 
from the program 1322, the program 1323 updates the 
number of cases in the records respectively associated 
with the pertinent transmission source, type of 
5 information, and kind of items, and type of products as 
well as the update day and time. Thereafter, the program 
1323 increases or decreases the total number of cases for 
the type of information in the summary table in relation 
to the increase or decrease in the detailed table. 
10 Fig. 18B is a flowchart showing an operation 

flow of the program 1323 achieved on receiving an enquiry 
*S for the service status database 1313 from the client 

1305. When an enquiry for the database 1313 is received 
;\L; from the client 1305, there is achieved authentication of 

■^^ 15 the user by a member management server, not shown. If 

the user is assumed to be authorized, control is 
m transferred to the program 1323 of the service status 

iij server 1304. The program 1323 receives the enquiry 

request from the client 1305 (step 1861). The request 
20 data includes an identifier of the member to which the 
client 1305 belongs. The program 1323 refers to the 
database 1313 to acquire therefrom the total numbers 
respectively of the business and message cases related to 
the member (information receiving partner) and a receiver 
25 table of the member (step 1862) so as to edit the 

obtained service status information (step 1863), In the 
operation, the program 1323 converts the identifier of 
transmitting partner of the table into a firm name and an 
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office name and the information type flag into an 
associated name. Furthermore, the program 1323 adds a 
destination (e.g. , a host name) of the business server 
1302 managing the case data to each of the records in the 
5 receiver table. Finally, the program 1323 sends the 
resultant data via the network 1310 to the client 1305 
having issued the enquiry request (step 1864), vnien the 
enquiry from the client 1305 is associated with an open 
case, the program 1323 entirely obtains the detailed 

10 table from the database 1313 to edit the table and then 
transmits the table to the client 1305 . 

In the client 1305, an application program 
displays the service status information received from the 
program 1323 of the server 1304 on a display. When the 

15 user indicates a transmission source, a type of 

information, a degree of urgency, and a number of cases 
to be acquired, the application program issues an enquiry 
to a business server 1302 as the destination of the 
specified record by transferring thereto the transmission 

20 source, the type of information, the degree of urgency, 
and the number of cases to be acquired. Receiving the 
enquiry data, the server 1302 conducts a retrieval 
operation through the case database 1311 to obtain 
therefrom a specified number of cases which are 

25 associated with the transmission source, the type of 

information, and the degree of urgency and of which the 
read flag is set to "not read" . The server 1302 then 
sends the obtained cases via the network 1310 to the 
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client 1305 and then updates the read flag of the cases 
to "read (already received)". The application program of 
the client 1305 presents the acquired case data on the 
display in accordance with an indication from the user, 
5 The program then transmits an acquisition report to the 
status management program 1322. The report includes, in 
addition to the identifier of the receiving partner, the 
numbers of attained cases respectively for the type of 
information and the degree of urgency of the acquired 

10 cases. However, when there is continuously executed 
processing to refer to and or update the case database 
1311 for the obtained cases in accordance with, e.g., the 
type of cases, the state is set to "in operation" such 
that the client 1305 does not issue the acquisition 

15 report in accordance with an indication from the user. 
An enquiry of an open case from the client 1305 is 
similarly processed- Namely, at reception of the enquiry 
request, the server 1302 obtains from the case database 
1311 the specified number of cases which are associated 

20 with the specified transmission source, the type of 
information, the kind of business, and the type of 
products and then sends the cases to the client 1305. 
The client 1305 displays the acquired case data on the 
display. However, the client 1305 does send the 

25 acquisition report to the status management program 1322. 

In this connection, the method above of 
classifying cases in which the numbers of cases collected 
respectively for each receiving partner and each 
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transmitting source has been described only as an 
example. There may be employed any other classifying 
method, for example, a method of classifying cases for 
each type thereof. Although the classifying method is 
5 closely associated with the present invention, the gist 
of the present invention resides in that there is 
controlled such information representing statuses of 
inputted cases as a list of quantitative values such as 
the number of cases and a list of titles of inputted 

10 cases so as to supply responses to enquiry requests from 
the members . 

In accordance with the embodiments , a business 
server 1302 is arranged for each information transmission 
source and the service status server 1304 is disposed as 

15 an independent server. However, it is to be appreciated 
that the embodiments can be implemented regardless of the 
correspondence between the functions respectively of the 
business and service status servers and the servers as 
computer hardware in which the databases and programs to 

20 realize the functions above are stored. 

While the present invention has been described 
with reference to the particular illustrative 
embodiments, it is not to be restricted by those 
embodiments but only by the appended claims. It is to be 

25 appreciated that those skilled in the art can change or 
modify the embodiments without departing from the scope 
and spirit of the present invention- 



